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Verfahren zur Unterstutzung des Name Delivery Leistungsmerk- 
males fur gemischte TDM Netze/. SIP CENTREX Kornmunikationsar- 
chitekturen 

Die Erfindung betrifft ein Verfahren gemass dem Oberbegriff 
von Patentanspruch l.Neuere Kommunikationsarchitekturen sehen 
die Trennung vermittlungstechnischer Netzwerke in verbin- 
dungsdienstbezogene Einheiten und den Transport der Nutzin- 
formationen (Bearer Control) vor. Hieraus resultiert eine De- 
komposition/ Trennung von Verbindungsaufbau und Medium-bzw. 
Beareraufbau. Die Obertragung der Nutzinformationen (Durch- 
schaltung des Nutzkanals) kann dabei iiber unterschiedliche 
hochbitratige Transporttechnologien wie z.B. ATM, IP, Frame 
Relay vorgenommen werden. Mit einer derartigen Trennung sind 
die gegenwartig in Schmalbandnetzen gefiihrten Telekommunika- 
tionsdienste auch in Breitbandnetzen zu realisieren. Dabei 
werden die Teilnehmer entweder direkt (z.B. iiber ein DSS1- 
Protokoll) oder iiber als Media Gateway Controller (MGC) aus- 
gebildete Vermittlungsstellen (z. B. iiber das ISUP-Protokoll) 
angeschlossen . Die Nutzinformationen selbst werden iiber von 
Media Gateways (MG) in die jeweils benutzte Transporttechno- 
logie umgewandelt. Die Steuerung der Media Gateways werden 
von jeweils zugeordneten Media Gateway Controllern (MGC) 
durchgefiihrt . Zur Steuerung der Media Gateways verwenden die 
Media Gateway Controller normierte Protokolle, wie z. B. das 
MGCP Protokoll oder das H.248 Protokoll. Zur Kommunikation 
untereinander verwenden die Media Gateway Controller ein 
durch die ITU standardisiertes BICC (Bearer Independent Call 
Control) Protokoll, das eine Weiterentwicklung eines ISUP 
Protokolls darstellt. Das BICC Protokoll wird aus einer Mehr- 
zahl von standardisierten Protokollen gebildet und umfasst 
somit eine Protokollf amilie . 

Dem BICC Protokoll adaquate Protokolle sind bei dem IETF 
Standardisierungsgremium mit den SIP und SIP-T Protokollen 
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entstanden. Das SIP-T Protokoll (RFC 3204) stellt dabei einen 
Zusatz zum SIP Protokoll (RFC 3261) dar. Mit Hilfe des SIP-T 
Protokolls konnen ISUP-Nachrichten - im Gegensatz zum SIP 
Protokoll - iibertragen werden. Die Obertragung der ISUP- 
5 Nachrichten erfolgt im Allgemeinen durch Tunneln, d.h. durch 
transparentes Durchreichen. Vorzugsweise werden die von einem 
PSTN-Teilnehmer abgegebenen ISUP-Nachrichten zusammen mit ei- 
ner Tragernachricht gefiihrt (INFO Methode, RFC 2 976) und dem 
empfangenden PSTN-Teilnehmer zugeleitet. In Fig. 1 ist eine 

10 derartige, allgemeine Netzkonf iguration mit TDM -/ IP Netzen 
aufgezeigt. Hierbei sind beispielhaft 2 PSTN-Netze offenbart, 
in denen jeweils eine Mehrzahl von PSTN-Teilnehmern in be- 
kannter Weise angeordnet sind. Diese sind an Ortsvermitt- 
lungsstellen LE herangefiihrt, die ihrerseits mit Transit- 

15 Vermittlungsstellen TX verbunden sind. In den Transit- 

Vermittlungsstellen TX wird nun die Trennung zwischen Signa- 
lisierungsinf ormationen und Nutzinf ormationen durchgefuhrt . 
Die Signalisierungsinf ormationen werden von der Transit- 
Vermittlungsstelle TX unmittelbar uber ein ISUP- Protokoll 

20 einem jeweils zugeordneten Media Gateway Controller MGC (der 
A- oder B-Seite) zugefuhrt. Die Nutzinf ormationen werden zu 
einem (eingangsseitig angeordneten) Media Gateway MG (der A- 
oder B-Seite) iibertragen, das als Schnittstelle zwischen TDM- 
Net z und einem ATM- bzw. IP- Ubertragungsnetz fungiert, wo 

25 sie uber das betreffende Ubertragungsnetz (ATM bzw. IP) pa- 
ketorientiert iibertragen werden. Das Media Gateway MG der A- 
Seite wird von dem jeweils zugeordneten Media Gateway Cont- 
roller MGC der A-Seite ebenso gesteuert, wie das Media Gate- 
way MG der B-Seite von dem diesem zugeordneten Media Gateway 

30 Controller MGC der B-Seite. Im Falle einer Ubertragung der 

Nutzinformationen vom Media Gateway MG der A-Seite zum Media 
Gateway MG der B-Seite werden diese wieder unter Steuerung 
des dem Media Gateway MG der B-Seite zugeordneten Media Gate- 
way Controllers MGC der B-Seite in einen TDM Datenstrom umge- 

35 wandelt und dem in Frage kommenden PSTN-Teilnehmer zugefuhrt 
werden. Die zwischen dem Media Gateway Controller MGC und dem 
jeweils zugeordneten Media Gateway iibertragenen Daten werden 
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von einem standardisierten Protokoll unterstutzt. Dieses kann 
beispielsweise das MGCP oder das H.248 Protokoll sein. Zwi- 
schen den beiden Media Gateway' Controllern MGC konnen als 
standardisierte Protokolle ein BICC Protokoll (bzw. ISUP+ 
5 Protokoll), ein SIP- oder SIP-T Protokoll vorgesehen sein. 

Zwischen beiden Media Gateway Controllern konnen noch weitere 
Einrichtungen wie Proxy-Einrichtungen (SIP-Welt) und/ oder 
CMN Vermittlungsstellen (Call Mediation Node, ISUP/ BICC- 
Welt) geschaltet sein. Grundsatzlich ist es wiinschenswert,. 

10 dass die aus der TDM Welt bekannten Leistungsmerkmale auch in 
der IP Welt verwendet werden konnen. Als Beispiel hierfur sei 
das Leistungsmerkmal Name Delivery angefiihrt, das bei her- 
kommlichen (TDM) CENTREX Teilnehmern bekannt ist. Hierbei 
wird unter einer CENTREX (Central Office Exchange) Konfigura- 

15 tion eine Konf iguration verstanden, die die Realisierung von 
Leistungsmerkmalen einer Nebenstellenanlage in Teilnehmerver- 
mittlungsstellen des offentlichen Netzes vorsieht. Werden die 
Anschlusse einer Benutzergruppe miteinander liber CENTREX Ver- 
mittlungsstellen und das offentliche Telefonnetz verbunden, 

20 spricht man von Wide Area CENTREX. Potentielle Nutzer von 
CENTREX-Diensten sind somit: 

- Gruppen mit haufigem Ortswechsel. 

- Grosse zusammenhangende Komplexe f wie Hochhauser, Techno- 
25 logie- und Medienzentren, Flughafen, 

- Gruppen mit dezentralen Strukturen, die hohenlnternverkehr 
zwischen den unterschiedlichen Standorten erzeugen. 

Ferner ist in Fig. 1 ist die Anbindung einer SIP CENTREX Kon- 
30 figuration aufgezeigt, wie sie liber einen SIP Proxy Server an 
einen Media Gateway Controller MGC herangeftihrt ist. Die In- 
formationen zwischen den SIP Teilnehmern einer SIP CENTREX 
Konfiguration werden mit Hilfe des SIP Protokolls ausge- 
tauscht. Im SIP Proxy Server werden alle teilnehmerbezogenen 
35 Daten der CENTREX Konfiguration verwaltet und gepflegt. 
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Bei einer derartigen Konf iguration gemass Fig. 1 besteht nun 
das Problem, dass im Mischbetrieb (Interworking) von TDM Net- 
zen/ IP Netzen/ SIP CENTREX Konf igurationen/ TDM CENTREX Kon- 
f igurationen das aus der TDM' Welt fur CENTREX Konf igurationen 
5 bekannte Leistungsmerkmal Name Delivery hier nicht verwendet 
werden kann, da die zur Realisierung notwendigen Festlegungen 
noch nicht erfolgt sind. 

Der Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzei- 
10 gen, wie das Leistungsmerkmal Name Delivery auch fur Netze 

mit gemischten TDM Konf igurationen/ SIP CENTREX Konf iguratio- 
nen verwendet werden kann. 

Die Erfindung wird ausgehend von den im Oberbegriff von 
15 Patentanspruch 1 angegebenen Merkmalen durch die im 
kennzeichnenden Teil beanspruchten Merkmale gelost. 

Der Vorteil der Erfindung ist darin zu sehen, dass bei Ver- 
wendung von SIP CENTREX Konf igurationen jedem beliebigen 

20 Teilnehmer (SIP Oder traditioneller TDM Teilnehmer) der Name 
des anderen Teilnehmers (Partner) angezeigt wird. Ein weitere 
Vorteil der Erfindung ist darin zu sehen, dass das Leistungs- 
merkmal Name Delivery auch in I SUP/ BICC/ H323 Netzen im In- 
terworking zum SIP Netz ohne Einschrankung verwendet werden 

25 kann. Das Leistungsmerkmal Name Delivery umfasst dabei die 
Teilfeature "Calling Name'' (Anzeige des Namens des rufenden 
Teilnehmers) sowie "Connected Name" (Anzeige des Namens des 
gerufenen Teilnehmers bei Annahme des Rufes) . 

30 Vorteilhafte Weiterbildungen der Erfindung sind in den Unter- 
anspruchen angegeben. 

Die Erfindung wird im folgenden anhand eines figurlich darge- 
stellten Ausfiihrungsbeispiels naher erlautert. 

35 



WO 2005/025172 



PCT/EP2004/051957 



5 

Es zeigen: 

Figur 1 die Verhaltnisse zwischen 2 PSTN-Netzen, zwischen 
denen ein* Internetnetz angeordnet ist, sowie mit 
5 einer SIP CENTREX Konf iguration, 

die Anbindung einer SIP CENTREX Konf iguration an 
ein Internetnetz mit den fur die Realisierung des 
Leistungsmerkmales Name Delivery notwendigen Infor- 
mationselementen 

Gemass Fig. 2 ist die Erfindung anhand eines Ausfiihrungsbei- 
spiels naher erlautert. Hierbei wird davon ausgegangen, dass 
der Teilnehmer eines TDM Netzes (A-Seite) den SIP Teilnehmer 
15 (B-Seite) einer SIP CENTREX Konf iguration - im vorliegenden 
Fall den Teilnehmer SIP B - anruft. Die Signalisierungsver- 
bindung soli dabei iiber einen SIP Proxy (Application Server) 
Server gefiihrt werden, der das Leistungsmerkmal Name Delivery 
unterstiitzt. 

20 

Zur Realisierung sind zunachst die Festlegungen gemass TAB 1 
fur das Mapping beim Ubergang ISUP/ BICC auf SIP und umge- 
kehrt zu treffen. Das Mapping wird im Media Gateway Control- 
ler MGC der B-Seite gesteuert (Obwohl die Controllerfunktio- 

25 nalitat hier ausgeblendet ist, da kein Media Gateway vorhan- 
den ist, wird die Einrichtung MGC der B-Seite als Media Gate- 
way Controller bezeichnet) . Da das Leistungsmerkmal Name De- 
livery fur TDM CENTREX Konf iguration gemass dem Stand der 
Technik (ISUP/ BICC) iiber proprietare Losungen gesteuert 

30 wird, werden die Namensinf ormationen in unterschiedlichen 
Protokollelementen des ISUP/ BICC Protokolls gefiihrt. Bei- 
spielhaft seien hier zwei Anbieter Al, A2 aufgezeigt. Im Fal- 
le von Al wird beispielsweise die Namensinformation im ISUP/ 
BICC Protokollelement "CallingName" gefiihrt^ im Falle eines 

35 Anbieters A2 im ISUP/BICC Protokollelement "CTX coding/ deco- 
ding" (APP Parameter (application transport parameter) basie- 
rend auf ITU-T Recommendation Q.7 65) . In letzterem Fall wird 
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hier auch die Namensinf ormation fur das Teilfeature ''Connec- 
ted Name" geftihrt. 



Anbieter 


ISUP/ BICC 


SIP 


A1 


CallingName 


Display field in FROM header/ 
privacy header 


A2:CTXASE calling 
name 


CTX coding/decoding 


Display field in FROM header/ 
privacy header 


A 2 : CTX ASE connected 
name 


CTX coding/decoding 


Display name of the CONTACT 
Header/ privacy header 



5 TAB 1 

Erf indungsgemaii wird nun (TAB 1, rechte Spalte) in einem ers- 
ten Schritt vorgesehen, die Namensinf ormationen fur das Teil- 
feature "Calling Name", grundsatzlich in das Protokollelement 
10 des SIP Protokolls "Display ' field in FROM header/ privacy 

header" zu ubertragen (Mapping) . Im Falle des Teilfeatures 
"Connected Name" soli die Namensinf ormation im SIP Protokoll- 
element "Display name of the CONTACT Header/ privacy header" 
geftihrt werden. 

15 

In einem zweiten Schritt sind nun die weiteren Aktionen in 
TAB 2 aufgezeigt. Die Namensinf ormationen werden in den SIP 
Protokollelementen "Display field in FROM header/ privacy 
header" dem Proxy Server SIP Proxy uber die SIP Nachricht 

20 "INVITE" zugefiihrt. Dieser iiberpruft zunachst, ob der gerufe- 
ne Teilnehmer SIP B die Namensanzeige des rufdnden Teilneh- 
mers gestattet oder beantragt hat (gebiihrenpf lichtiger 
Dienst) . Dies ist moglich, da der Proxy Server die hierzu re- 
levanten Daten in einer Datenbank abgelegt hat. Diese kann 

25 eine interne Datenbank im Proxy Server selbst sein, sie kann 
aber auch extern mit diesem verbunden sein. In der Datenbank 
kann auch eine Information dariiber abgelegt sein, ob der ru- 
fende Teilnehmer die Anzeige seines Namens wunscht oder 
nicht. Gestattet der gerufene Teilnehmer SIP B keine Namens- 
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anzeige des rufenden Teilnehmers, wird vom Proxy Server die 
Namensinformation dem SIP Protokollelement "Display field in 
FROM header/ privacy header" entfernt. 



10 



Andernfalls wird die Namens anzeige der Datenbank entnommen 
und in das Protokollelement "Display field in FROM header/ 
privacy header" eingefiigt. Falls die Namensanzeige bereits 
vorhanden ist, "wird keinerlei Eingriff vorgenommen . Die Na- 
mensinformation wird im Protokollelement "Display field in 
FROM header/ privacy header" dem gerufenen Teilnehmer SIP B 



SIP 


Proxy Server (SIP Proxy) 
Abfrage der Datenbank 


SIP 


FROM header/ privacy 
header 


Wird das Leistungsmerkmal Name 
Delivery (Calling Name) vom gerufe- 
nen Teilnehmer gewunscht ? 


Add or remove Display 
field in FROM 
header/privacy header 


CONTACT Header/ 
privacy header 


Wird das Leistungsmerkmal Name 
Delivery (Connected Name) vom 
gerufenen Teilnehmer gewunscht ? 


Display name of the 
CONTACT Header/ 
privacy header 



TAB 2 

15 Im folgenden wird nun davon ausgegangen, dass der gerufene 

Teilnehmer SIP B den Ruf annimrnt. Uber die SIP Quittungsnach- 
richt 200 OK wird die Namensinformation des gerufenen SIP 
Teilnehmers SIP B gefiihrt und im Proxy Server ausgewertet. 
1st die Namensanzeige beim rufenden Teilnehmer zugelassen, 

20 wird diese im SIP Protokollelement "Display name of the 

CONTACT Header/ privacy header" eingefiigt, oder entnommen , 
falls die Anzeige unterdriickt werden soil. 

Es ist zu beachten, dass die Erfindung auch angewendet werden 
25 kann, wenn es keinen ISUP/ BICC Protokolle zwischen dem PSTN 
Teilnehmer (ISDN, Analoger Teilnehmer oder auch Mobilfunk 
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Teilnehmer) und dem SIP Teilnehmer gibt. Dies bedeutet, dass 
das Verfahren dann innerhalb der Vermittlungsstelle stattfin- 
det. Das Interworklng von NextGenerationNetwork Teilnehmern 
wie VoDSL, H323 etc. zu SIP bzw. SIP-T wird damit ebenfalls 
5 moglich. 

Bei dem soeben beschriebenen Verfahren ist eine Trennung der 
Verfahrensablaufe im Media Gateway Controller und dem Proxy 
Server vorgenommen worden. Diese Trennung ist aber nicht 
10 zwingend f der Ablauf des Verfahrens kann auch innerhalb eine 
einzigen Einrichtung stattfinden. 
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Patentansprtiche 

1. Verfahren zur Unterstiitzung cies Leistungsmerkmales Name 
Delivery, mit TDM Netzen, die an SIP CENTREX Konf igurationen 

5 herangefiihrt sind, wobei die fur das Leistungsmerkmal Name 
Delivery relevanten Inf ormationen Namensinf ormationen sind, 
die in mehreren, sich unterscheidenden Inf ormationselementen 
eines Ubertragungsprotokolls iibertragen werden konnen, 
dadurch gekennzeichnet , 

10 dass zwischen den in mehreren, sich unterscheidenden Informa- 
tionselementen des Ubertragungsprotokolls gefuhrten Namensin- 
formationen und den Inf ormationselementen eines SIP Proto- 
kolls ("Display field in FROM header/ privacy header ", "Dis- 
play name of the CONTACT Header/ privacy header") ein Mapping 

15 vorgenommen wird, 

dass nach Mafigabe von teilnehmerbezogenen Inf ormationen die 
Namensinformationen in den Inf ormationselementen des SIP Pro- 
tokolls ("Display field in FROM header/ privacy header") un- 
terdriickt oder zugelassen werden, 

20 

2. Verfahren nach Anspruch 1, 
dadurch gekennzeichnet, 

dass das Leistungsmerkmal Name Delivery aus jeweils zwei 
Teilfeatures (Calling Name, Connected Name) ausgebildet ist. 

25 

3. Verfahren nach Anspruch 1, 2, 
i. dadurch gekennzeichnet, 

dass das Mapping zwischen den in mehreren, sich unterschei- 
denden Informationselementen des Ubertragungsprotokolls ge- 

30 fiihrten Namensinformationen des ersten Teilfeatures in ein 
erstens Inf ormationselement des SIP Protokolls ("Display 
field in FROM header/ privacy header"), und das Mapping zwi- 
schen den in mehreren, sich .unterscheidenden Informationsele- 
menten des Obertragungsprotokolls gefiihrten Namensinf ormatio- 

35 nen des zweiten Teilfeatures in ein zweites Inf ormationsele- 
ment des SIP Protokolls ("Display name of the CONTACT Header/ 
privacy header") vorgenommen wird. 



WO 2005/025172 PCT/EP2004/051957 



10 

4. Verfahren nach Anspruch 1 bis 3, 
dadurch gekennzeichnet , 

dass die Namensinf ormation des ersten Teilfeatures in dem In- 
formationselement der SIP Nachricht "INVITE" und die Namens- 
5 information des zweiten Teilfeatures in dem Inf ormationsele- 
ment der SIP Nachricht "200 OK" gefuhrt werden. 

5. Verfahren nach Anspruch 1 bis 4, 
dadurch g e k e n n z e i c h n e t , 

10 dass ein SIP Proxy Server vorgesehen wird, der in Wirkverbin- 
dung mit einer Datenbank steht. 

6. Verfahren nach Anspruch 5, 
dadurch g e k e n n z e i c h n e t , 

15 dass in der Datenbank teilnehmerbezogene Daten der Teilnehmer 
der SIP CENTREX Konf iguration und des TDM Netzes gefuhrt wer- 
den . 

7. Verfahren nach einem der vorstehenden Anspruche, 
20 dadurch g e k e n n z e i c h n e t , 

dass das Mapping in einem Media Gateway Controller (MGC) vor- 
genommen wird. 

8. Verfahren nach einem der vorstehenden Anspruche, 
25 dadurch gekennzeich.net, 

dass vom Proxy Server nach Matigabe der in der Datenbank ge- 
fuhrten teilnehmerbezogenen Inf ormationen entschieden wird, 
ob die Namensinformationen unterdriickt oder zugelassen wer- 
den. 

30 

9. Verfahren nach einem der vorstehenden Ansprtiche, 
dadurch gekennzeichnet, 

dass das Obertragungsprotokoll als BICC/ ISUP Protokoll, als 
H.323 Protokoll, als DSS1 Protokoll oder als ein Mobilfunkan- 
35 wendungen unterstiitzendes Protokoll ausgebildet ist. 
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